The term upgrading a software application generally refers to the process of replacing an existing version of the software application with a newer version or adding a new version of the software application where none previously existed. A software upgrade may be performed for various reasons such as to add one or more features, remove one or more features, modify one or more features from an existing version of the software, remove bugs or errors, improve the software efficiency, and other reasons. An upgrade is generally performed to enhance the performance of the software application.
Many modern computing environments typically include a framework of multiple software applications, which may be developed by different third-party entities. Each software application may include zero or more plugins. The plugins may include software components that add a new utility/feature or enhance the utilities/features of a software application. The applications may run on or be hosted by multiple host machines (“hosts”) in a distributed environment, with each host potentially hosting multiple applications. Performing an upgrade operation in such a distributed environment comprises multiple upgrade processes executed by multiple hosts such that one or more upgrade processes may be executed to upgrade each application. Many of the upgrade processes may be executed in parallel. Possible dependencies among the upgrade processes further complicate the overall upgrade.
Some conventional upgrade mechanisms include a framework for generating timing reports but the information shown by these reports is very limited. For example, while conventional reports may show the start and end time of an overall upgrade operation that comprises multiple upgrade processes running on multiple host machines and total time of the overall upgrade executing on the multiple host machines, they fail to show useful information such as timing information for each host machine among the multiple host machines. The existing timing report tools are not able to distinguish between the execution time of upgrade processes on a given host, the operational idle time (i.e., idle time) of the host (e.g., when no upgrade processes execute on the host) and the time the host spent on coordinating with peer hosts. In addition, existing timing report tools are not able to report how many times the upgrade processes are re-run.
In some implementations, a reporting tool may use log files generated on the one or more hosts involved in the upgrade operations to generate a timing report. In such an implementation, each host involved in the upgrade operation is forced to store log files storing some timing information associated with that host. Further, all the log file generated by the multiple hosts have to follow the same logging format (e.g., use the same nomenclature to mark the milestones of the upgrade processes running on each host) so that the reporting tool can parse the logs appropriately in order to generate the timing report. A log-based timing report system also is not extensible, for example when a new host is added to the overall upgrade operation. In addition, log files occupy a lot of memory resources and, as a result, some implementations may not archive the log files, or may purge the archived log files due to disk space limitations. In such implementations, the log-based timing report solutions do not work properly. Moreover, when multiple upgrade processes are executed concurrently, a user will have to manually review the log files to find overlapping execution times among hosts. The task becomes even more difficult when the log files do not distinguish between the times when upgrade processes execute on the host and no upgrade processes execute on the host. Additionally, the log files may be stored at multiple locations on multiple hosts and some may not be accessible due to a variety of reasons, such as, security concerns. This prevents a reporting tool from generating a comprehensive image of all the upgrade processes running on multiple hosts as part of the overall upgrade operation.